home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 5601 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.7 KB
  1. Path: rcp6.elan.af.mil!rscernix!danpop
  2. From: danpop@mail.cern.ch (Dan Pop)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: memory allocation using malloc and free
  5. Date: 19 Feb 96 22:13:00 GMT
  6. Organization: CERN European Lab for Particle Physics
  7. Message-ID: <danpop.824767980@rscernix>
  8. References: <4gagll$5rc@bertrand.ccs.carleton.ca>
  9. NNTP-Posting-Host: ues5.cern.ch
  10. X-Newsreader: NN version 6.5.0 #7 (NOV)
  11.  
  12. In <4gagll$5rc@bertrand.ccs.carleton.ca> tcope@chat.carleton.ca (Tyler Cope) writes:
  13.  
  14. >Could someone please demonstrate the proper (or _a_ proper) ANSI
  15. >method of allocating >64K space using malloc and free. I've tried many
  16. >versions and most work when malloc() and free() are both called from
  17. >main(), but when a separate function is called, everything goes crazy.
  18.  
  19. There is no proper way to use malloc to allocate more bytes than can
  20. be stored in a size_t variable, for the simple reason that the prototype
  21. of malloc is:
  22.  
  23.     void *malloc(size_t size);
  24.  
  25. If size_t is a 16-bit unsigned integer type on your platform, 64k is a
  26. hard limit for malloc.
  27.  
  28. An apparent workaround would be to use calloc instead, because it has
  29. two size_t arguments.  In practice, calloc is not able to allocate more
  30. bytes than malloc, however.
  31.  
  32. If size_t is larger than 16 bits, the restrictions on the maximum memory
  33. block that can be allocated using malloc are usually imposed by external 
  34. factors (e.g. the amount of physical or virtual memory available to the
  35. program when malloc was called).
  36.  
  37. The usual workaround on unextended MSDOS is to use vendor-specific
  38. functions which take long or unsigned long arguments.  Of course, this
  39. has nothing to do with ANSI C any longer.
  40.  
  41. Dan
  42. --
  43. Dan Pop
  44. CERN, CN Division
  45. Email: danpop@mail.cern.ch 
  46. Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
  47.